Procedure a function
Otázka od: Petr K.
10. 9. 2002 19:23
Zdravim , napis zni asi divne, ale potrebuju trochu poradit.
Mam deklarovanou nejakou svoji funkci a je tam napr.
Function Texty(a,b:String;c:Integer):String;
Begin
<neco>
End;
Jde mi o to ze obcas nepotrebuju vyplnovat promennou c jde to nak udelat aby
byla k dispozici jen volitelne?
to znamena pouzit obe syntaxe (ja vim ze to takhle fungovat nebude, ale tak
nak bych si to predstavoval) / naivne 
1. Texty(a,b);
2. Texty(a,b,c);
Dik Petr
Odpovedá: Petr Vones
11. 9. 2002 4:05
From: "Petr K." <xdelphi@seznam.cz>
> Mam deklarovanou nejakou svoji funkci a je tam napr.
>
> Function Texty(a,b:String;c:Integer):String;
> Begin
> <neco>
> End;
>
> Jde mi o to ze obcas nepotrebuju vyplnovat promennou c jde to nak udelat aby
> byla k dispozici jen volitelne?
1. Pretezovanim
function Texty(const A, B: string): string; overload;
begin
end;
function Texty(const A, B: string; C: Integer): string; overload;
begin
end;
2. Jako default parametr:
function Texty(const A, B: string; C: Integer = 0): string;
begin
end;
Petr Vones
Odpovedá: Radim Kunz
11. 9. 2002 5:55
----- Original Message -----
From: "Petr K." <xdelphi@seznam.cz>
To: "Delphi clexpert" <delphi-l@clexpert.cz>
Sent: Tuesday, September 10, 2002 8:17 PM
Subject: Procedure a function
> Zdravim , napis zni asi divne, ale potrebuju trochu poradit.
>
> Mam deklarovanou nejakou svoji funkci a je tam napr.
>
> Function Texty(a,b:String;c:Integer):String;
> Begin
> <neco>
> End;
>
> Jde mi o to ze obcas nepotrebuju vyplnovat promennou c jde to nak udelat
aby
> byla k dispozici jen volitelne?
>
> to znamena pouzit obe syntaxe (ja vim ze to takhle fungovat nebude, ale
tak
> nak bych si to predstavoval) / naivne
> 1. Texty(a,b);
> 2. Texty(a,b,c);
>
> Dik Petr
>
>
bud
function Texty(a,b:string;c:integer=0);
...
nebo
function Texty(a,b:string;c:integer); overload;
...
function Texty(a,b:string); overload;
...
Radim
Odpovedá: ing. Jan Fiala
11. 9. 2002 7:22
Function Texty(a,b:String;c:Integer=0):String;
--
ing. Jan Fiala
mailto:jan.fiala@iol.cz
10.9.2002 Petr K.:
> Zdravim , napis zni asi divne, ale potrebuju trochu poradit.
> Mam deklarovanou nejakou svoji funkci a je tam napr.
> Function Texty(a,b:String;c:Integer):String;
> Begin
> <neco>
> End;
> Jde mi o to ze obcas nepotrebuju vyplnovat promennou c jde to nak udelat aby
> byla k dispozici jen volitelne?
> to znamena pouzit obe syntaxe (ja vim ze to takhle fungovat nebude, ale tak
> nak bych si to predstavoval) / naivne
> 1. Texty(a,b);
> 2. Texty(a,b,c);
> Dik Petr
Odpovedá: Jan Sebelík
12. 9. 2002 1:28
> Odesílatel: Petr Vones <pvones@mbox.vol.cz>
> 1. Pretezovanim
> 2. Jako default parametr:
Jenom bych snad podtrhl, ze to nelze kombinovat: bud 1. nebo 2.
Tedy nelze
function Texty(const A, B: string; C: Integer = 0): string; overload;
function Texty(const A, B: string; C: Integer): string; overload;
protoze kompilator by pri volani Texty(a,b,c) nepoznal, kterou funkci chci
vlastne zavolat.
Pokud jde o me, pretezovani nemam moc rad. Je to trochu "nepascalovske".
Jako ortodoxni pascalista bych radsi napsal dve ruzne funkce bez overload:
function Texty(const A, B: string): string;
function TextyC(const A, B: string; C: Integer): string;
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================
Odpovedá: Erik Salaj
12. 9. 2002 18:20
> > Pokud jde o me, pretezovani nemam moc rad. Je to trochu "nepascalovske".
>
> Je, a je to tak dobre. Nastesti se Object Pascal v Delphi vyviji vcelku
> spravnym smerem 
mozno by bolo dobre aj pripisat, preco je to tak dobre. Pretazovanie
je totiz velmi diskutabilna zalezitost a nemyslim si, ze je nejakym extra
(resp. vobec) prinosom. Ak dve metody oznacis rovnakym identifikatorom,
stracas moznost jednoducho identifikovat metodu podla nazvu
(prakticky sa tento problem prejavi ak chces napr. taku metodu
exportovat z DLL). Pritom overloading neprinasa nic nove
do programovania, je to len syntakticka zalezitost, ze namiesto toho,
aby programator poriadne identifikoval co treba, prenechava sa tato
uloha kompilatoru.
Myslim, ze programy, kde sa pouziva overloading su menej citatelne
(najprv treba zistit podla parametrov, ktora metoda sa vlastne vola),
neskor mozu vzniknut problemy a konflikty, ak sa parametre
takychto metod zmenia.
Oveloading je podporovany v C#, s tym, ze C# neumoznuje definovat
default hodnoty parametrov. Eiffel overloading vobec neumoznuje
a vyhyba sa tak zbytocnym problemom.
Erik
Odpovedá: Erik Salaj
12. 9. 2002 19:57
> > Jako ortodoxni pascalista bych radsi napsal dve ruzne funkce bez
> > overload:
> function Texty(const A, B: string): string;
> function TextyC(const A, B: string; C: Integer): string;
>
> pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
> komplikovany algoritmus, bude navrzene reseni znamenat, ze az se najde
chyba,
> budes muset nezapomenout opravit obe funkce, zatimco jediny zdrojak s
> parametrem s implicitni hodnotou v takovem pripade zjednodusi udrzbu. Je
mi jasne,
> ze implicitni parametr neni pretezovani, ale predpokladam, ze prvni radek
se tyka i
> toho.
ak obidva funkcie obsahuju nejaky spolocny alebo podobny kod, tak je
snad daleko rozumnejsie urobit este jednu proceduru s tymto spolocnym
kodom a potom vo funkciach len zavolat tuto proceduru.
Erik
Odpovedá: Petr Vones
12. 9. 2002 4:39
From: "Jan Sebelík" <honza@haes.cz>
> Pokud jde o me, pretezovani nemam moc rad. Je to trochu "nepascalovske".
Je, a je to tak dobre. Nastesti se Object Pascal v Delphi vyviji vcelku
spravnym smerem
Petr Vones
Odpovedá: Lebeda David
12. 9. 2002 10:37
> Pokud jde o me, pretezovani nemam moc rad. Je to
> trochu "nepascalovske".
>
> Jako ortodoxni pascalista bych radsi napsal dve ruzne funkce bez
> overload:
function Texty(const A, B: string): string;
function TextyC(const A, B: string; C: Integer): string;
Ahoj,
pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
komplikovany algoritmus, bude navrzene reseni znamenat, ze az se najde chyba,
budes muset nezapomenout opravit obe funkce, zatimco jediny zdrojak s
parametrem s implicitni hodnotou v takovem pripade zjednodusi udrzbu. Je mi
jasne,
ze implicitni parametr neni pretezovani, ale predpokladam, ze prvni radek se
tyka i
toho.
David Lebeda
Odpovedá: Petr Fejfar
13. 9. 2002 6:24
From: "Lebeda David" <david.lebeda@comarr.cz>
> pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
> komplikovany algoritmus, bude navrzene reseni znamenat, ze az se najde
> chyba, budes muset nezapomenout opravit obe funkce,
To se prece dela tak, ze se napise jen funkce s obecnejsim interfacem tj.v
tomto pripade s povinnym parametrem a ta druha by ji volala s nejakou dummy
hodnotu. Ostatne u overload techniky by to vypadalo stejne.
Nadbytecny overhead toho vnoreneho volani podprogramu lze kompenzovat prave
uzitim default hodnoty argumentu, ale zalezi na typu aplikace
1) z hlediska lepsi modifikovatelnosti bych preferoval overload techniku,
protoze mohou existovat dalsi pozadavky napr. na pridani dalsich argumentu
do vypoctu, ktere uz technikou nepovinnych argumentu nevyresim
2) z hlediska potencialne vyssi spolehlivosti kodu bych preferoval techniku
nepretezovanych funkci s ruznymi jmeny, protoze pri pripadne zmene spojene
napr. s prejmenovavanim a zmenou argumentu mi prekladac ukaze dotcena volani
a mel bych se tudiz zamyslet, jaky dopad muze mit provadena zmena
na ruzne casti programu, o kterych uz davno nikdo nevi, ze v programu jsou.
Bye, pf
Odpovedá: Marek Dostál
13. 9. 2002 1:23
> > Jako ortodoxni pascalista bych radsi napsal dve ruzne funkce bez
> > overload:
> function Texty(const A, B: string): string;
> function TextyC(const A, B: string; C: Integer): string;
>
> Ahoj,
>
> pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
> komplikovany algoritmus, bude navrzene reseni znamenat, ze az se najde chyba,
> budes muset nezapomenout opravit obe funkce, zatimco jediny zdrojak s
Nebudes, kdyz v Texty zavolas TextyC...:
function Texty(const A, B: string): string;
begin
...algoritmus
end;
function Texty(const A, B: string): string;
begin
TextyC(A,B,0);
end;
Odpovedá: Erik Salaj
13. 9. 2002 1:36
> Je to vyhodne tam, kdy (zpravidla jednoducha) funkce muze mit ruzne typy
> parametru avsak vykonava logicky totez. Napriklad:
>
> function Trim(const S: string): string; overload;
> function Trim(const S: WideString): WideString; overload;
>
> Je (alespon dle meho nazoru) lepsi nez nejake hruzy jako TrimAnsi,
TrimWide a
> podobne, ktere si clovek musi pamatovat.
jedna z moznosti je, ze Trim je priamo sucastou objektu AnsiString
alebo WideString (nie v Delphi ale napr. v OOP frameworkoch
ako .NET, Eiffel alebo aj Smalltalk) a overloading vobec netreba.
Moze sa ale samozrejme vyskytnut v inych pripadoch, chcel som
len ukazat, ze poriadna podpora dolezitych aspektov OOP
moze niektore problemy (aspon ciastocne) eliminovat.
Ja nevidim ziadny problem pomenovat funkcie TrimAnsiString
a TrimWideString a zbavit sa tak problemov s jednoznacnou
identifikaciou. Myslim, ze je jednoduchsie oznacenie funkcie
jednym identifikatorom
TrimAnsiString
ako syntaktickou konstrukciou
Trim(const S: AnsiString)
---------------------------------------------------------------
Zoberme takyto overloading, je to ok, alebo nie?
Trim(const S: AnsiString)
Trim(S: AnsiString)
A volanie metody:
Trim("ABC"); // ktora metoda sa zavola?
Trim(ABC); // ktora metoda sa zavola?
Alebo tento overloading:
Add(Value: Integer);
Add(Value: LongInt);
Add(5); // ktora metoda sa zavola?
Add(LongInt(5)); // teraz ktora?
> Dalsi vyuziti muze byt u zajisteni zpetne kompatibility.
???
> > (prakticky sa tento problem prejavi ak chces napr. taku metodu
> > exportovat z DLL). Pritom overloading neprinasa nic nove
>
> Coz neni zase tak bezna vec.
no bol to priklad z Delphi, kde sa tento problem prejavil. Ja sa
overloadingu vyhybam, teda zaroven aj podobnym problemom,
ale myslim, ze ako nazorna ukazka, ze tam problemy vznikaju
to moze posluzit. Ak by tam tie problemy neboli, tak nie je
problem overloading implementovat do (takmer) kazdeho
jazyka a pouzivat (a nebol by dovod o tom ani diskutovat).
Ale ak nic ine, tak je dobre o moznych problemoch aspon vediet.
> > Myslim, ze programy, kde sa pouziva overloading su menej citatelne
> > (najprv treba zistit podla parametrov, ktora metoda sa vlastne vola),
> > neskor mozu vzniknut problemy a konflikty, ak sa parametre
> > takychto metod zmenia.
>
> To je pravda, jenze pro mozne spatne pouziti jeste neznamena celou vec
> zatratit.
podla mna treba zvazit prinosy aj zapory a tak sa rozhodnut. Problem
s overloadingom vidim hlavne v tom, ze tych prinosov je tam minimum.
Erik
Odpovedá: Jan Sebelík
13. 9. 2002 3:22
> Odesílatel: Lebeda David <david.lebeda@comarr.cz>
> function Texty(const A, B: string): string;
> function TextyC(const A, B: string; C: Integer): string;
>
> pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
> komplikovany algoritmus, bude navrzene reseni znamenat, ze az se najde chyba,
> budes muset nezapomenout opravit obe funkce, zatimco jediny zdrojak s
> parametrem s implicitni hodnotou v takovem pripade zjednodusi udrzbu. Je mi
jasne,
> ze implicitni parametr neni pretezovani, ale predpokladam, ze prvni radek se
tyka i
> toho.
Ne, mluvil jsem vyhradne o pretezovani.
Mozna si (jako ortodoxni pascalista 
protirecim, ale proti implicitnim
parametrum nic nemam (sdilim tedy vsechny tvoje argumenty), zatimco to
pretezovani (overload) mi nejak vadi.
Priklad (mozna za vlasy pritazeny):
function Deleni(x,y:Integer):Integer; overload;
function Deleni(x,y:Double):Double; overload;
Pri volani funkce
x:=5; y:=2; z:=Deleni(x,y);
pak vysledek zavisi na tom, jak jsou deklarovany promenne x, y.
Z uvedeneho radku vubec nepoznam, kterou funkci si kompilator vybral.
U implicitnich parametru podobna nedorozumeni nehrozi.
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================
Odpovedá: Daniel Frantik
13. 9. 2002 7:46
No, jen pro presnost.
function Texty(const A, B: string): string;
begin
Result:=TextyC(A,B,0);
end;
Danik
> > Pokud jde o me, pretezovani nemam moc rad. Je to
> > trochu "nepascalovske".
> >
> > Jako ortodoxni pascalista bych radsi napsal dve ruzne funkce bez
> > overload:
> function Texty(const A, B: string): string;
> function TextyC(const A, B: string; C: Integer): string;
>
> Ahoj,
>
> pokud ale obe funkce budou obsahovat velmi podobny, presto ale dlouhy
> komplikovany algoritmus, bude navrzene reseni znamenat, ze az
> se najde chyba,
> budes muset nezapomenout opravit obe funkce, zatimco jediny zdrojak s
> parametrem s implicitni hodnotou v takovem pripade zjednodusi
> udrzbu.
Odpovedá: Petr Vones
12. 9. 2002 19:27
From: "Erik Salaj" <winsoft@stonline.sk>
> mozno by bolo dobre aj pripisat, preco je to tak dobre. Pretazovanie
> je totiz velmi diskutabilna zalezitost a nemyslim si, ze je nejakym extra
> (resp. vobec) prinosom. Ak dve metody oznacis rovnakym identifikatorom,
> stracas moznost jednoducho identifikovat metodu podla nazvu
Je to vyhodne tam, kdy (zpravidla jednoducha) funkce muze mit ruzne typy
parametru avsak vykonava logicky totez. Napriklad:
function Trim(const S: string): string; overload;
function Trim(const S: WideString): WideString; overload;
Je (alespon dle meho nazoru) lepsi nez nejake hruzy jako TrimAnsi, TrimWide a
podobne, ktere si clovek musi pamatovat.
Dalsi vyuziti muze byt u zajisteni zpetne kompatibility.
> (prakticky sa tento problem prejavi ak chces napr. taku metodu
> exportovat z DLL). Pritom overloading neprinasa nic nove
Coz neni zase tak bezna vec.
> Myslim, ze programy, kde sa pouziva overloading su menej citatelne
> (najprv treba zistit podla parametrov, ktora metoda sa vlastne vola),
> neskor mozu vzniknut problemy a konflikty, ak sa parametre
> takychto metod zmenia.
To je pravda, jenze pro mozne spatne pouziti jeste neznamena celou vec
zatratit.
Petr Vones
Odpovedá: Petr Vones
13. 9. 2002 1:46
From: "Erik Salaj" <winsoft@stonline.sk>
> jedna z moznosti je, ze Trim je priamo sucastou objektu AnsiString
> alebo WideString (nie v Delphi ale napr. v OOP frameworkoch
Samozrejme, tohle je idealni reseni, ale na nej bude treba si v Delphi jeste
asi chvili pockat.
> Zoberme takyto overloading, je to ok, alebo nie?
>
> Trim(const S: AnsiString)
> Trim(S: AnsiString)
Neni, protoze z hlediska rozliseni jednoznacnosti pro pretezovani se jedna o
shodne deklarace funkci a dojde k chybe pri prekladu 'Identifier redeclared'.
Zajimavejsi je treba tohle:
Trim(const S: AnsiString)
Trim(S: PChar)
> A volanie metody:
>
> Trim("ABC"); // ktora metoda sa zavola?
> Trim(ABC); // ktora metoda sa zavola?
Zde zalezi na pravidlech konverze retezcovych konstant. Ano, prave u dvojice
string / PChar to bylo problematicke a pokud vim doslo k mirne zmene pravidel
mezi ruznymi verzemi prekladace. To se dale tyka i typu Variant a TObject /
Pointer / IInterface pri predani nil konstanty.
> Alebo tento overloading:
>
> Add(Value: Integer);
> Add(Value: LongInt);
Stejny pripad jako vyse. Pri navrhu se samozrejme s timto pocitalo, analyza se
neprovadi jen prostym porovnanim jmen typu parametru
> > Dalsi vyuziti muze byt u zajisteni zpetne kompatibility.
>
> ???
Napriklad v nove verzi se ukaze, ze by do nejake funkce bylo vhodne pridat
nebo zmenit parametr, nebo ze konverze API funkce do Object Pascalu byla
chybna. Zaroven je ale snaha zachovat kompilaci existujiciho kodu bez nutnosti
opravy na novou syntaxi. Tady se prave hodi pretezovani.
> no bol to priklad z Delphi, kde sa tento problem prejavil. Ja sa
Zpusob exportovani pretezovanych funkci je popsan v helpu pod heslem
'The
exports clause' a spociva jen v definici jednoznacneho jmena pro export.
> to moze posluzit. Ak by tam tie problemy neboli, tak nie je
> problem overloading implementovat do (takmer) kazdeho
> jazyka a pouzivat (a nebol by dovod o tom ani diskutovat).
Moderni jazyky jako C++ nebo C# jej maji, to byl mozna i jeden z duvodu proc
byl implementovan i do Delphi.
> podla mna treba zvazit prinosy aj zapory a tak sa rozhodnut. Problem
> s overloadingom vidim hlavne v tom, ze tych prinosov je tam minimum.
To je vec nazoru, nikdo nikoho nenuti jej pouzivat.
Petr Vones
Odpovedá: Petr Vones
13. 9. 2002 3:58
From: "Jan Sebelík" <honza@haes.cz>
> function Deleni(x,y:Integer):Integer; overload;
> function Deleni(x,y:Double):Double; overload;
>
> Pri volani funkce
> x:=5; y:=2; z:=Deleni(x,y);
> pak vysledek zavisi na tom, jak jsou deklarovany promenne x, y.
> Z uvedeneho radku vubec nepoznam, kterou funkci si kompilator vybral.
To je ucelem, funkce Deleni ma prece vydelit dve cisla. Smyslem pretezovani
neni prece vytvorit neco sileneho, kdy se zamenou typu jednoho z parametru
provede zcela jina operace (i kdyz to tak samozrejme lze zneuzit
Petr Vones
Odpovedá: Jan Sebelík
13. 9. 2002 14:21
> Odesílatel: Petr Fejfar <development@callnet.cz>
> 2) z hlediska potencialne vyssi spolehlivosti kodu bych preferoval techniku
> nepretezovanych funkci s ruznymi jmeny, protoze pri pripadne zmene spojene
> napr. s prejmenovavanim a zmenou argumentu mi prekladac ukaze dotcena volani
> a mel bych se tudiz zamyslet, jaky dopad muze mit provadena zmena
> na ruzne casti programu, o kterych uz davno nikdo nevi, ze v programu jsou.
Presne takto byly motivovany moje argumenty v predchozi diskusi.
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================
Odpovedá: Erik Salaj
13. 9. 2002 23:38
> > Zoberme takyto overloading, je to ok, alebo nie?
> >
> > Trim(const S: AnsiString)
> > Trim(S: AnsiString)
>
> Neni, protoze z hlediska rozliseni jednoznacnosti pro pretezovani se jedna
o
> shodne deklarace funkci a dojde k chybe pri prekladu
'Identifier
redeclared'.
ale v C++ to je korektny overloading
> > Trim("ABC"); // ktora metoda sa zavola?
> > Trim(ABC); // ktora metoda sa zavola?
>
> Zde zalezi na pravidlech konverze retezcovych konstant. Ano, prave u
dvojice
> string / PChar to bylo problematicke a pokud vim doslo k mirne zmene
pravidel
> mezi ruznymi verzemi prekladace. To se dale tyka i typu Variant a TObject
/
> Pointer / IInterface pri predani nil konstanty.
cize musim poznat urcite pravidla, aby som to mohol korektne pouzit.
Ak sa ale v pravidlach pomylim, prekladac ma neupozorni, ale pouzije
inu funkciu ako ja zamyslam. Nijako sa mi to nepaci - zbytocne
robit vedu s pravidlami (a systemy typov to veda naozaj je)
tam, kde to nie je potrebne.
> > Alebo tento overloading:
> >
> > Add(Value: Integer);
> > Add(Value: LongInt);
>
> Stejny pripad jako vyse. Pri navrhu se samozrejme s timto pocitalo,
analyza se
> neprovadi jen prostym porovnanim jmen typu parametru
zase otazka: a preco nie? Preco su take pravidla a nie ine? Ved Integer
je jeden typ a LongInt iny. Zase tvrdim, ze taketo vselijake pravidla
su perfektnym zdrojom zakernych chyb v programoch. Preco
programator musi robit detailnu typovu analyzu, aby si bol isty,
ze kompilator pouzije tu funkciu, ktoru ten programator chce pouzit?
Totoo ja nijako nemozem nazvat prinosom do programovania.
> > > Dalsi vyuziti muze byt u zajisteni zpetne kompatibility.
> >
> > ???
>
> Napriklad v nove verzi se ukaze, ze by do nejake funkce bylo vhodne pridat
> nebo zmenit parametr, nebo ze konverze API funkce do Object Pascalu byla
> chybna. Zaroven je ale snaha zachovat kompilaci existujiciho kodu bez
nutnosti
> opravy na novou syntaxi. Tady se prave hodi pretezovani.
tak si predstav, ze mam dve funkcie
Func(a, b: Integer);
Func(a, b: Real);
a niekde v programe pouzivam
Func(1, 2); // zavola Integer funkciu
A. teraz zmazem funkciu Func(a, b: Integer). Co to urobi
s programom? Len to, ze miesto Integer zrazu kompilator
zavola Real funkciu, bez warningu, bez upozornenia - skratka
zmazanim funkcie (alebo aj pridanim funkcie, ci zmenou
parametrov) sa moze zmenit vyznam programu (moze to
zmenit vyznam uplne inej casti programu, nez kde doslo
k zmene) a ja ako programator jednoducho nemam sancu
tomu zabranit (akurat davat pozor alebo po kazdej zmene
prehladavat vsetky zdrojaky, ci nahodou nebol, nie je,
alebo nevznikne nahodou pretazenie a nespravne pouzitie).
> > no bol to priklad z Delphi, kde sa tento problem prejavil. Ja sa
>
> Zpusob exportovani pretezovanych funkci je popsan v helpu pod heslem
'The
> exports clause' a spociva jen v definici jednoznacneho jmena pro
export.
jednoznacnost je zasadna vec a to nie len pre DLL-ka. V Eiffely
sa vyuziva pri viacnasobnej dedicnosti, kde je mozne presne
urcit kedy co sa ma ako dedit. Ak to ma byt jasne, jednoznacne
a jednoduche, tak tam nejednoznacne pomenovania jednoducho
nemaju miesto. Ak pouzivas dedicnost, co je zasadny prostriedok
na dosiahnutie znovupouzitelnosti, tak az by si dedil vlastnosti
z x tried a kombinoval to s overloadingom, tak Ti asi zostane
iba jedina moznot - hadat, ze kedy sa ktora metoda zavola.
> > to moze posluzit. Ak by tam tie problemy neboli, tak nie je
> > problem overloading implementovat do (takmer) kazdeho
> > jazyka a pouzivat (a nebol by dovod o tom ani diskutovat).
>
> Moderni jazyky jako C++ nebo C# jej maji, to byl mozna i jeden z duvodu
proc
> byl implementovan i do Delphi.
podla mna hlavny dovod v Delphi bol ten, ze je to jednoducho
implementovatelne. Ziadny mimoriadny efekt sa tym nesledoval
(ani sa to nijakym zasadnym sposobom pokial viem vo VCL
nepouziva), ale snat islo o drobne "vylepsenie" aby bol dovod
na upgrade.
Zamyslal som sa, nad tym preco je oveloading aj v C# (C++
za moderny jazyk nepovazujem) a predpokladam, ze to suvisi
s dalsim obmedzenim tohto jazyka (prevzatym z C++),
ze konstruktor musi mat pevne stanovene meno - rovnake
ako nazov triedy. Ak teda ma by moznost roznej incializacie
triedy (co sa casto v praxi vyuziva), tak jedinym riesenim
je tu potom overloading. V Eiffely taketo obmedzenie
neexistuje, tam mozes lubovolnu funkciu oznacit ako
kontruktor a pouzivat ju ako kontruktor ale (zase na
rozdiel od C++/C#) aj volat ako obycajnu metodu:
class TEST
create
make -- tuto feature bude mozne pouzit na konstrukciu
feature
make is
do
...
end
end -- TEST
...
a: TEST
...
create a.make -- konstruktor
a.make -- obycajne volanie metody
...
> > podla mna treba zvazit prinosy aj zapory a tak sa rozhodnut. Problem
> > s overloadingom vidim hlavne v tom, ze tych prinosov je tam minimum.
>
> To je vec nazoru, nikdo nikoho nenuti jej pouzivat.
nie je to len otazka pouzivania, je to otazka charakteru jazyka. Ak jazyk
povoluje nejaku "nebezpecnu" konstrukciu, tak na nu mozem doplatit
aj vtedy, ked ju nepouzivam, pretoze kompilator ju akceptuje a teda
ma neupozorni - ja sam MUSIM davat na to pozor.
Erik
Odpovedá: Erik Salaj
14. 9. 2002 2:34
> > cize musim poznat urcite pravidla, aby som to mohol korektne pouzit.
>
> Jako se vsim.
no hej, problem je v tom, ze nie su pravidla ako pravidla
> > tak si predstav, ze mam dve funkcie
> >
> > Func(a, b: Integer);
> > Func(a, b: Real);
>
> Ne, pokud mam dve takove funkce tak prece nebude kazda provadet neco
jineho,
tie funkcie musia robit nieco ine uz len preto, ze dostanu ine parametre
> navic v danem unitu prece neni takovy problem se podivat co presne delam.
> Stejne tak mohu zmenit vyznam programu tak ze nekde umazu nejake cislo v
> konstante a podobne.
lenze, ked zmenim hodnotu nejakej kostanty, tak sa nemeni ta cast programu,
ktora tu konstantu nepouziva. Ale zmenou nejakej pretazenej funkcie sa moze
zmenit cast programu, ktora tuto funkciu nepouzivala (ak pouzivala tu druhu
pretazenu funkciu a dojte zhodou okolnosti, k tomu, ze parametre budu
po zmene "lepsie odpovedat" tej prvej pretazenej funkcii). Teda zmenim
nejaku funkciu a zrazu prestane fungovat cast programu, ktora tuto funkciu
nikdy nepouzivala - dost vazny problem podla mna. Chces konkretny priklad?
> > sa vyuziva pri viacnasobnej dedicnosti, kde je mozne presne
> > urcit kedy co sa ma ako dedit. Ak to ma byt jasne, jednoznacne
>
> Exportovani overloaded funkci nema vubec nic spolecneho s dedicnosti.
to si nejako zle precital, co som napisal. Hovoril som o tom, ze overloading
moze sposobit problemy v kombinacii s dedicnostou.
> Rozhodne to nebylo jednoduche implementovat. Uz jen proto, ze se musel
> napriklad zmenit name-mangling algoritums pro jmena exportovanych
metod/funkci
> v baliccich a stanovit pravidla pro nejednoznacne pripady, jako napriklad
nil.
pokial viem, tak back-end Delphi kompilatora je zhodny s C++ Builderom
(teda overloading tam uz davno je), takze stacilo doplnit podporu
do front-endu. Overloading (a rovnako tak default parametre) je
z hladiska kompilatora jednoducha zalezitost: co sa tyka generovaneho
kodu (to je zvycajne hlavny problem dobreho kompilatora - generovat
dobry kod), tak tam ziadna zmena nie je potrebna (okrem toho name-
manglingu, ten ale s kodom priamo nesuvisi). Inac ten name-mangling
samotny je podla mna odporna vec a je to presne jeden z dosledkov
overloadingu.
> Prikladem je treba prace s ukazateli nebo 'tvrde' pretypovani, tam ti
> kompilator nepomuze vubec.
ak myslis tvrdym pretypovanim, explicitne pretypovanie, tak to je
v poriadku, programator jasne napise svoj zamer pretypovat,
kompilator skontroluje a ak je to ok, tak pretypuje - nevidim
nic zle na tom. Nebezpecne su len implicitne pretypovania
(v niektorych pripadoch, teda netreba to prilis prehanat).
> Chapu ze se ti ta vlastnost nelibi protoze neni v Eiffelu, ale to jeste
> neznamena ze pri vhodnem pouziti nemusi byt uzitecna.
su aj ine dovody. Ale ten Eiffel ma nieco do seba, to je fakt.
Jeho prinos je aj v tom, ze programatora (alebo navrhara,
ci analytika) nechava riesit naozaj realne problemy tykajuce
sa objektoveho modelovania a nie pseudoproblemy vzniknute
v dosledku zleho navrhu nastroja na objektove modelovanie.
X problemov, ktore su povedzme v Delphi alebo C++,
v Eiffeli jednoducho nie je. Na objekty sa pozeras ako
na skutocne objekty a nie ako na smerniky, ci struktury
s procedurami, ci kus kodu alebo pameti.
Na zaver snad, ak niekto vidi overloading ako prinosnu vec, tak sa
mozme pokusit pouvazovat nad dalsim rozvinutim tejto myslienky,
povedzme co tak overloading premennych:
var
a: Integer;
a: Real;
a := 1; // do Integer
a := 3.4; // do Real
if (a = 3) then // false
if (a = 3.4) then // true
if (a = 1) and (a = 3.4) then // true, ved ziadny problem zaroven 1 aj 3.4
Vyhoda je takisto jasna - netreba zbytocne vymyslat nove nazvy premennym,
ved nazov ako nazov
Erik
Odpovedá: Erik Salaj
14. 9. 2002 11:52
> > tie funkcie musia robit nieco ine uz len preto, ze dostanu ine
> > parametre
>
> Samozrejme, jedna treba scita cela cisla, a druha realna, kdyz
> vymyslim co nejtrivialnejsi priklad.
a to je podla Teba to iste?
> Jooo, kdyz neumis pouzivat pretizene funkce, tak je nepouzivej. Pokud
> nekdo napise funkci na vypocet trajektorie druzice kolem Zeme, a pak
> dalsi pretizenou funkci pro vypocet optimalni drahy drbani na zadech,
> pak je to cune a nema radeji programovat. Pokud ale nekdo napise
> funkci pro trajektorie americke druzice, a pak totez potrebuje i pro
> ruskou druzici, ale tam je treba predat parametry v jinych typech,
> pak je cas na pretizeni.
tam je cas dat vypocet drahy americkej druzice do objektu
americkej druzice a vypocet drahu ruskej druzice do objektu
ruskej druzite a overloading nepotrebujes.
Erik
Odpovedá: Erik Salaj
14. 9. 2002 10:43
> Pokud nejsi cune a neresis v kazde funkci neco jineho, tak nic.
> Nanejvys ti program ohlasi konflikt typu. A prave tam, kde by ke
> konfliktu typu mohlo dojit, se pouziva pretezovani.
zrejme preto, aby som sa konflikt typov nedal jednoducho odhalit
> > podla mna hlavny dovod v Delphi bol ten, ze je to jednoducho
> > implementovatelne. Ziadny mimoriadny efekt sa tym nesledoval
> > (ani sa to nijakym zasadnym sposobom pokial viem vo VCL
> > nepouziva), ale snat islo o drobne "vylepsenie" aby bol dovod
> > na upgrade.
>
> A nebylo by vhodnejsi se podivat do zdrojaku VCL, ktere funkce, jak a
> proc jsou pretizene? Mozna by ti to neco napovedelo.
co konkretne je takym prinosom overloadingu vo VCL?
> > nie je to len otazka pouzivania, je to otazka charakteru jazyka. Ak
> > jazyk povoluje nejaku "nebezpecnu" konstrukciu, tak na nu mozem
> > doplatit aj vtedy, ked ju nepouzivam, pretoze kompilator ju akceptuje
> > a teda ma neupozorni - ja sam MUSIM davat na to pozor.
>
> V tom pripade radeji ani neprechazej ulici, protoze musis myslet na
> to, ze se mas rozhlednout, aby te nic neprejelo...
ale ked tam bude semafor, tak vtedy by nemal byt s tym problem, vsak?
Erik
Odpovedá: Petr Vones
14. 9. 2002 0:39
From: "Erik Salaj" <winsoft@stonline.sk>
> cize musim poznat urcite pravidla, aby som to mohol korektne pouzit.
Jako se vsim.
> zase otazka: a preco nie? Preco su take pravidla a nie ine? Ved Integer
> je jeden typ a LongInt iny. Zase tvrdim, ze taketo vselijake pravidla
Podobne jako muzes predat coby Integer parametr promennou typu Longint.
Predstav si to jako aliasy k typum.
> tak si predstav, ze mam dve funkcie
>
> Func(a, b: Integer);
> Func(a, b: Real);
>
> a niekde v programe pouzivam
>
> Func(1, 2); // zavola Integer funkciu
>
> A. teraz zmazem funkciu Func(a, b: Integer). Co to urobi
> s programom? Len to, ze miesto Integer zrazu kompilator
> zavola Real funkciu, bez warningu, bez upozornenia - skratka
> zmazanim funkcie (alebo aj pridanim funkcie, ci zmenou
> parametrov) sa moze zmenit vyznam programu (moze to
Ne, pokud mam dve takove funkce tak prece nebude kazda provadet neco jineho,
navic v danem unitu prece neni takovy problem se podivat co presne delam.
Stejne tak mohu zmenit vyznam programu tak ze nekde umazu nejake cislo v
konstante a podobne.
> sa vyuziva pri viacnasobnej dedicnosti, kde je mozne presne
> urcit kedy co sa ma ako dedit. Ak to ma byt jasne, jednoznacne
Exportovani overloaded funkci nema vubec nic spolecneho s dedicnosti.
> podla mna hlavny dovod v Delphi bol ten, ze je to jednoducho
> implementovatelne. Ziadny mimoriadny efekt sa tym nesledoval
Rozhodne to nebylo jednoduche implementovat. Uz jen proto, ze se musel
napriklad zmenit name-mangling algoritums pro jmena exportovanych metod/funkci
v baliccich a stanovit pravidla pro nejednoznacne pripady, jako napriklad nil.
> nie je to len otazka pouzivania, je to otazka charakteru jazyka. Ak jazyk
> povoluje nejaku "nebezpecnu" konstrukciu, tak na nu mozem doplatit
> aj vtedy, ked ju nepouzivam, pretoze kompilator ju akceptuje a teda
> ma neupozorni - ja sam MUSIM davat na to pozor.
Prikladem je treba prace s ukazateli nebo 'tvrde' pretypovani, tam ti
kompilator nepomuze vubec.
Chapu ze se ti ta vlastnost nelibi protoze neni v Eiffelu, ale to jeste
neznamena ze pri vhodnem pouziti nemusi byt uzitecna.
Petr Vones
Odpovedá: Zbysek Hlinka
14. 9. 2002 8:09
On 13 Sep 2002 at 15:29, Erik Salaj wrote:
> > > tak si predstav, ze mam dve funkcie
> > >
> > > Func(a, b: Integer);
> > > Func(a, b: Real);
> >
> > Ne, pokud mam dve takove funkce tak prece nebude kazda provadet neco
> jineho,
>
> tie funkcie musia robit nieco ine uz len preto, ze dostanu ine
> parametre
Samozrejme, jedna treba scita cela cisla, a druha realna, kdyz
vymyslim co nejtrivialnejsi priklad.
> > navic v danem unitu prece neni takovy problem se podivat co presne
> > delam. Stejne tak mohu zmenit vyznam programu tak ze nekde umazu
> > nejake cislo v konstante a podobne.
>
> lenze, ked zmenim hodnotu nejakej kostanty, tak sa nemeni ta cast
> programu, ktora tu konstantu nepouziva. Ale zmenou nejakej pretazenej
> funkcie sa moze zmenit cast programu, ktora tuto funkciu nepouzivala
> (ak pouzivala tu druhu pretazenu funkciu a dojte zhodou okolnosti, k
> tomu, ze parametre budu po zmene "lepsie odpovedat" tej prvej
> pretazenej funkcii). Teda zmenim nejaku funkciu a zrazu prestane
> fungovat cast programu, ktora tuto funkciu nikdy nepouzivala - dost
> vazny problem podla mna. Chces konkretny priklad?
Jooo, kdyz neumis pouzivat pretizene funkce, tak je nepouzivej. Pokud
nekdo napise funkci na vypocet trajektorie druzice kolem Zeme, a pak
dalsi pretizenou funkci pro vypocet optimalni drahy drbani na zadech,
pak je to cune a nema radeji programovat. Pokud ale nekdo napise
funkci pro trajektorie americke druzice, a pak totez potrebuje i pro
ruskou druzici, ale tam je treba predat parametry v jinych typech,
pak je cas na pretizeni.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Zbysek Hlinka
14. 9. 2002 8:23
On 13 Sep 2002 at 11:21, Erik Salaj wrote:
> Func(a, b: Integer);
> Func(a, b: Real);
>
> a niekde v programe pouzivam
>
> Func(1, 2); // zavola Integer funkciu
>
> A. teraz zmazem funkciu Func(a, b: Integer). Co to urobi
> s programom?
Pokud nejsi cune a neresis v kazde funkci neco jineho, tak nic.
Nanejvys ti program ohlasi konflikt typu. A prave tam, kde by ke
konfliktu typu mohlo dojit, se pouziva pretezovani.
> podla mna hlavny dovod v Delphi bol ten, ze je to jednoducho
> implementovatelne. Ziadny mimoriadny efekt sa tym nesledoval
> (ani sa to nijakym zasadnym sposobom pokial viem vo VCL
> nepouziva), ale snat islo o drobne "vylepsenie" aby bol dovod
> na upgrade.
A nebylo by vhodnejsi se podivat do zdrojaku VCL, ktere funkce, jak a
proc jsou pretizene? Mozna by ti to neco napovedelo.
> nie je to len otazka pouzivania, je to otazka charakteru jazyka. Ak
> jazyk povoluje nejaku "nebezpecnu" konstrukciu, tak na nu mozem
> doplatit aj vtedy, ked ju nepouzivam, pretoze kompilator ju akceptuje
> a teda ma neupozorni - ja sam MUSIM davat na to pozor.
V tom pripade radeji ani neprechazej ulici, protoze musis myslet na
to, ze se mas rozhlednout, aby te nic neprejelo...
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Erik Salaj
14. 9. 2002 22:44
> > > V tom pripade radeji ani neprechazej ulici, protoze musis myslet na
> > > to, ze se mas rozhlednout, aby te nic neprejelo...
> >
> > ale ked tam bude semafor, tak vtedy by nemal byt s tym problem, vsak?
>
> Ano, vsude jsou semafory. 
A pokud nahodou ne, mas asi smulu.
ale riesenie so semaformi mozem povazovat za prinos a davat
mu prednost (ak mam na vyber) pred riesenim bez semaforu.
Prechadzanie cez cestu vsade kde sa mi zachce moze byt sice
rychlejsie a pohodlnejsie ale zaroven musim podstupit riziko,
ze na to mozem doplatit.
> Pretezovani je uzitecny nastroj, a nikdo te nenuti ho pouzivat.
> Nedostatek jazyka nespociva ani tak v tom, co umoznuje, ale spis v
> tom, co neumoznuje.
s nazorom, ze viac je vzdy lepsie sa nestotoznujem
Erik
Odpovedá: Erik Salaj
14. 9. 2002 23:11
> Ano. Potrebuji secist dve veliciny. V tomto smyslu je pretizeny i
> operator +, protoze jednou scita cela cisla, jindy realna, a jindy
> retezce. Nevadi ti to? Podle toho co pises, by ti to vadit melo.
lenze si uvedom, ze v OOP sa akakolvek operacia vztahuje vzdy
k objektu (v tomto pripade jednemu z operandov), teda pokial
to mam definovane takto:
class INTEGER
feature
infix +(operand: INTEGER) is ...
end -- INTEGER
class REAL
feature
infix +(operand: REAL) is ...
end -- REAL
class STRING
feature
infix +(operand: STRING) is ...
end -- STRING
tak kde tu mas overloading? Dalej chces povedat, ze su to
rovnake operacie? Podla mna kazda z tychto operacii je uplne ina.
> Dokumentace rika, ze pro vypocet trajektorie druzice se pouzije
> funkce VypoctiTrajektoriiDruzice. Pak se ale prijde na to, ze je
> treba pocitat jeste ruskou druzici, ktera ma ale ponekud odlisne
> vstupni parametry. Pri psani programu te prilis nezajima, jaka
> druzice se bude prave pocitat. Podobne te nezajima, co scitas. Ale
> abys nebyl zahlcen ruznymi jmeny, das pro stejnou funkcnost stejne
> jmeno a pak nemusis hledat, jak se ma funkce jmenovat pro jine
> vstupy.
>
> Krome toho, stejne se pro ruskou druzici nejspis vola funkce pro
> americkou druzici, pouze se provede konverze a pripadne nejaky
> prepocet tak, abys pak mohl pouzit stejny algoritmus.
zda sa mi ako vyhodnejsie pouzit tu dedicnost a polymorfizmus,
teda seriozne prostriedky OOP
Erik
Odpovedá: Zbysek Hlinka
14. 9. 2002 12:13
On 13 Sep 2002 at 23:33, Erik Salaj wrote:
> > > tie funkcie musia robit nieco ine uz len preto, ze dostanu ine
> > > parametre
> >
> > Samozrejme, jedna treba scita cela cisla, a druha realna, kdyz
> > vymyslim co nejtrivialnejsi priklad.
>
> a to je podla Teba to iste?
Ano. Potrebuji secist dve veliciny. V tomto smyslu je pretizeny i
operator +, protoze jednou scita cela cisla, jindy realna, a jindy
retezce. Nevadi ti to? Podle toho co pises, by ti to vadit melo.
> > Jooo, kdyz neumis pouzivat pretizene funkce, tak je nepouzivej.
> > Pokud nekdo napise funkci na vypocet trajektorie druzice kolem Zeme,
> > a pak dalsi pretizenou funkci pro vypocet optimalni drahy drbani na
> > zadech, pak je to cune a nema radeji programovat. Pokud ale nekdo
> > napise funkci pro trajektorie americke druzice, a pak totez
> > potrebuje i pro ruskou druzici, ale tam je treba predat parametry v
> > jinych typech, pak je cas na pretizeni.
>
> tam je cas dat vypocet drahy americkej druzice do objektu
> americkej druzice a vypocet drahu ruskej druzice do objektu
> ruskej druzite a overloading nepotrebujes.
Dokumentace rika, ze pro vypocet trajektorie druzice se pouzije
funkce VypoctiTrajektoriiDruzice. Pak se ale prijde na to, ze je
treba pocitat jeste ruskou druzici, ktera ma ale ponekud odlisne
vstupni parametry. Pri psani programu te prilis nezajima, jaka
druzice se bude prave pocitat. Podobne te nezajima, co scitas. Ale
abys nebyl zahlcen ruznymi jmeny, das pro stejnou funkcnost stejne
jmeno a pak nemusis hledat, jak se ma funkce jmenovat pro jine
vstupy.
Krome toho, stejne se pro ruskou druzici nejspis vola funkce pro
americkou druzici, pouze se provede konverze a pripadne nejaky
prepocet tak, abys pak mohl pouzit stejny algoritmus.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Zbysek Hlinka
14. 9. 2002 13:13
On 13 Sep 2002 at 23:39, Erik Salaj wrote:
> > V tom pripade radeji ani neprechazej ulici, protoze musis myslet na
> > to, ze se mas rozhlednout, aby te nic neprejelo...
>
> ale ked tam bude semafor, tak vtedy by nemal byt s tym problem, vsak?
Ano, vsude jsou semafory. A pokud nahodou ne, mas asi smulu.
Pretezovani je uzitecny nastroj, a nikdo te nenuti ho pouzivat.
Nedostatek jazyka nespociva ani tak v tom, co umoznuje, ale spis v
tom, co neumoznuje.
S pozdravem
Zbysek Hlinka
E-mail: hlinka@hlinka.cz, localizator@localizator.com
Phone: +420 603 551 282
Odpovedá: Erik Salaj
15. 9. 2002 17:34
> >> Samozrejme, jedna treba scita cela cisla, a druha realna, kdyz
> >> vymyslim co nejtrivialnejsi priklad.
>
> > a to je podla Teba to iste?
>
> a podla teba nie? Je pochopitelne, ze implementacia pre kazdy typ to urobi
> ako najlepsie to s danym typom dokaze. Nieco ako v tom vtipe:
ak tvrdis, ze scitanie je vzdy ta ista operacia, bez ohladu na typ objektu
na ktorom je definovana, tak mi ju tak spolocne popis (zadefinuj). Teda
co to scitanie vlastne je (resp. co mam robit s prvkami lubovolneho typu,
ak ich chcem scitat a co dostanem; a ak je tato operacia pouzitelna len
na niektore typy, tak aj vysvetli, na ktore typy mozem a ktore nemozem
pouzit tuto operaciu).
Erik
Odpovedá: Viliam Mlich
15. 9. 2002 12:30
>>> tak si predstav, ze mam dve funkcie
>>>
>>> Func(a, b: Integer);
>>> Func(a, b: Real);
>> Ne, pokud mam dve takove funkce tak prece nebude
>> kazda provadet neco jineho,
> tie funkcie musia robit nieco ine uz len preto, ze dostanu ine parametre
Len blazon by na jedno meno zavesil roznu funkcionalitu.
Overload je velmi uzitocna vlastnost, lebo pomaha zvysovat citatelnost
programu prave v pripadoch, ked nedokonalost jazyka inak nuti programatora
do zapisu algoritmu vkladat slova, ktore by zabalili myslienku do balastu
technickych detailov.
Napriklad datove typy shortstring, string, widestring, ansistring, pchar,
array of char - to vsetko je z pohladu algoritmu retazec, odlisny len
nepodstatnymi technickymi detailami a ja som nuteny pouzivat ich len kvoli
tomu, ze nejaky produkt tretej strany, co volam, vyzaduje urcity konkretny
typ.
Ked robim nejaku funkciu sam, napisem ju pre typ, ktory mi najlepsie
vyhovuje, a potom cez overload zadefinujem funkcie, ktore len prevedu
parametre na pozadovany format a zavolaju matersku implementaciu. Aby som sa
pri volani nemusel starat o pretypovania.
Podobny pripad su defaultne hodnoty. Ked nejaku funkciu 100x volam s default
hodnotou a potom 3x s niecim extra, ale funkcionalita je ta ista, nebudem
predsa pre tu funkcionalitu (napriklad 'inkrement') vymyslat nejake nove
meno! Alebo kazit zapis programu tym, ze na 100 miestach budem odovzdavat
konstantu 1! To uz neni ani buzeracia, ale rovno zvrhlost.
V pascale je v tomto bordel. Napriklad '+' funguje na Integer aj Real, ale
na delenie uz nutia programatora, aby sa dival do deklaracie a podla toho
pouzil '/' alebo 'div'. Ze tu je nebezpecie skrytej chyby? Nezmysel.
Algoritmus nesmie byt postaveny na type dat. V cobole boli vsetky cisla typu
'computational', skoda, ze neskor zacali zavadzat vsetky tie LongInty,
DoubleRealy a podobne nezmysly. 
bye
vmlich http://www.rar.cz
Odpovedá: Viliam Mlich
15. 9. 2002 12:43
>> Samozrejme, jedna treba scita cela cisla, a druha realna, kdyz
>> vymyslim co nejtrivialnejsi priklad.
> a to je podla Teba to iste?
a podla teba nie? Je pochopitelne, ze implementacia pre kazdy typ to urobi
ako najlepsie to s danym typom dokaze. Nieco ako v tom vtipe:
Vlk zdrapil zajaca a zrukol na neho:
- Preved operaciu 'vyfajcit' s mojim chujom ako parametrom!
- Nie! Ja to neviem!
- Ale uz aj!
- Ja to fakt neviem!
- Vyfajci mi ho tak, ako vies, lebo inak ta zozeriem!
- Tak dobre - strcil si zajko do huby koniec cerveny ako mrkvicka -
Chrum-chrum-chrum...
Ale v tej minulej sprave som sa este zabudol postazovat na jednu vec, co ma
v pascale otravuje: casto sa v mieste, kde sa ma odovzdat pole, dava len
jeden prvok. Bohuzial autori funkcii nepouzivaju overload, ale toto by mohlo
byt riesene aj na urovni Pascalu, ze jeden prvok by sa automaticky povazoval
za jednoprvkove pole.
bye
vmlich
Odpovedá: Erik Salaj
16. 9. 2002 1:42
> > tie funkcie musia robit nieco ine uz len preto, ze dostanu ine parametre
>
> Len blazon by na jedno meno zavesil roznu funkcionalitu.
skus si precitat nieco o polymorfizme - to je presne o tom, ze na jedno meno
zavesis roznym objektom roznu funkcionalitu
> Overload je velmi uzitocna vlastnost, lebo pomaha zvysovat citatelnost
> programu prave v pripadoch, ked nedokonalost jazyka inak nuti programatora
> do zapisu algoritmu vkladat slova, ktore by zabalili myslienku do balastu
> technickych detailov.
len skoda, ze riesenie s overloadingom ma neprijemne vedlajsie efekty.
Mozno rozumejsia alernativa je zdokonalovat nedokonalosti jazyka
inym sposobom.
> Napriklad datove typy shortstring, string, widestring, ansistring, pchar,
> array of char - to vsetko je z pohladu algoritmu retazec, odlisny len
> nepodstatnymi technickymi detailami a ja som nuteny pouzivat ich len kvoli
> tomu, ze nejaky produkt tretej strany, co volam, vyzaduje urcity konkretny
> typ.
ale z pohladu OOP to nie je ziadny overloading, ked objektom roznych typov
priradis metodu s rovnakym nazvom.
Erik
Odpovedá: Petr Vones
16. 9. 2002 1:58
From: "Erik Salaj" <winsoft@stonline.sk>
> > Len blazon by na jedno meno zavesil roznu funkcionalitu.
>
> skus si precitat nieco o polymorfizme - to je presne o tom, ze na jedno meno
> zavesis roznym objektom roznu funkcionalitu
'flat' funkce nemaji s OOP a polymorfismem nic spolecneho. Zkratka Object
Pascal je proceduralni jazyk s objektovym rozsirenim podobne jako C++. Ano,
muzeme se ted donekonecna bavit o cistote ryze OOP jazyku a tech ktere byly
takto pozdeji rozsireny.
Petr Vones
Odpovedá: Viliam Mlich
16. 9. 2002 6:39
Povodne som sa uz do tejto jalovej debaty nechcel zapajat, navyse moderator
tu nema zmysel pre radoby-vtipne prirovnania, ale k tomuto musim:
> ale z pohladu OOP to nie je ziadny overloading, ked objektom roznych typov
> priradis metodu s rovnakym nazvom.
Vyuzivanie tejto vlastnosti moze viest k daleko neprijemnejsim vedlajsim
efektom, nez overload, treba ju pouzivat mooc opatrne. Skoro by bolo rozumne
ju zakazat. Hlavne jej urcenie je to, ze ked pouzivam v projekte hodne
cudzich modulov, aby sa mi nepobili public identifikatory. Vsimni si, ze
stejne radsej kazdy pre poriadok pouziva pre svoj projekt prefix.
howgh
Odpovedá: Jan Sebelík
16. 9. 2002 11:17
> > skus si precitat nieco o polymorfizme - to je presne o tom, ze na jedno
meno
> > zavesis roznym objektom roznu funkcionalitu
Puvodne jsem tady vyjadril svuj skromny soukromy nazor - overloading NE.
Pritom nikoho nepremlouvam, aby to nepouzival.
Pak uz jsem diskusi jenom sledoval.
Ted se ale zase musim ozvat:
overloading a polymorfismus je uplne neco jineho.
O polymorfismu mluvime u objektu, ktere jsou navzajem oddedene.
Presneji receno maji nejakeho spolecneho obecnejsiho (abstraktnejsiho) predka.
Vzdyt take polymorfni metody casto byvaji "nekde nahore" abstraktni.
Polymorfni metoda je tedy primarne metodou jedine (obecnejsi) tridy, odvozene
(konkretnejsi) tridy ji jenom implementuji konkretnejsim zpusobem.
Navic polymorfni metody (samozrejme) musi mit tytez parametry.
Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 0434 692 569 (0776 347735)
=========================================